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Abstract 


As an optical signal progresses along its path, it may be altered by 
the various physical processes in the optical fibers and devices it 
encounters. When such alterations result in signal degradation, 
these processes are usually referred to as "impairments". These 
physical characteristics may be important constraints to consider 
when using a GMPLS control plane to support path setup and 
maintenance in wavelength switched optical networks. 


This document provides a framework for applying GMPLS protocols and 
the Path Computation Element (PCE) architecture to support 
Impairment-Aware Routing and Wavelength Assignment (IA-RWA) in 
wavelength switched optical networks. Specifically, this document 
discusses key computing constraints, scenarios, and architectural 
processes: routing, wavelength assignment, and impairment validation. 
This document does not define optical data plane aspects; impairment 
parameters; or measurement of, or assessment and qualification of, a 
route; rather, it describes the architectural and information 
components for protocol solutions. 
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Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6566. 


Copyright Notice 


Copyright (c) 2012 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Introduction 


Wavelength Switched Optical Networks (WSONs) are constructed from 
subsystems that may include wavelength division multiplexed links, 
tunable transmitters and receivers, Reconfigurable Optical Add/Drop 
Multiplexers (ROADMs), wavelength converters, and electro-optical 
network elements. A WSON is a Wavelength Division Multiplexing 
(WDM) -based optical network in which switching is performed 
selectively based on the center wavelength of an optical signal. 


As an optical signal progresses along its path, it may be altered by 
the various physical processes in the optical fibers and devices it 
encounters. When such alterations result in signal degradation, 
these processes are usually referred to as "impairments". Optical 
impairments accumulate along the path (without 3R regeneration 
[G.680]) traversed by the signal. They are influenced by the type of 
fiber used, the types and placement of various optical devices, and 
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the presence of other optical signals that may share a fiber segment 
along the signal’s path. The degradation of the optical signals due 
to impairments can result in unacceptable bit error rates or even a 
complete failure to demodulate and/or detect the received signal. 


In order to provision an optical connection (an optical path) through 
a WSON, a combination of path continuity, resource availability, and 
impairment constraints must be met to determine viable and optimal 

paths through the network. The determination of appropriate paths is 
known as Impairment-Aware Routing and Wavelength Assignment (IA-RWA). 


Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] provides 
a set of control plane protocols that can be used to operate networks 
ranging from packet switch capable networks to those networks that 
use time division multiplexing and WDM. The Path Computation Element 
(PCE) architecture [RFC4655] defines functional computation 
components that can be used in cooperation with the GMPLS control 
plane to compute and suggest appropriate paths. [RFC4054] provides 
an overview of optical impairments and their routing (path selection) 
implications for GMPLS. This document uses [G.680] and other ITU-T 
Recommendations as references for the optical data plane aspects. 


This document provides a framework for applying GMPLS protocols and 
the PCE architecture to the control and operation of IA-RWA for 
WSONs. To aid in this evaluation, this document provides an overview 
of the subsystems and processes that comprise WSONs and describes 
IA-RWA models based on the corresponding ITU-T Recommendations, so 
that the information requirements for use by GMPLS and PCE systems 
can be identified. This work will facilitate the development of 
protocol extensions in support of IA-RWA within the GMPLS and PCE 
protocol families. 


2. Terminology 
ADM: Add/Drop Multiplexer. An optical device used in WDM networks 


and composed of one or more line side ports and, typically, many 
tributary ports. 


Black Links: Black links refer to tributary interfaces where only 
link characteristics are defined. This approach enables 
transverse compatibility at the single-channel point using a 
direct wavelength-multiplexing configuration. 

CWDM: Coarse Wavelength Division Multiplexing 

DGD: Differential Group Delay 


DWDM: Dense Wavelength Division Multiplexing 
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FOADM: Fixed Optical Add/Drop Multiplexer 

GMPLS: Generalized Multi-Protocol Label Switching 

IA-RWA: Impairment-Aware Routing and Wavelength Assignment 

Line Side: In a WDM system, line side ports and links typically can 
carry the full multiplex of wavelength signals, as compared to 
tributary (add or drop ports), which typically carry a few 
(typically one) wavelength signals. 

NEs: Network Elements 

OADMs: Optical Add/Drop Multiplexers 


OSNR: Optical Signal-to-Noise Ratio 


OXC: Optical Cross-Connect. An optical switching element in which a 
signal on any input port can reach any output port. 


PCC: Path Computation Client. Any client application requesting that 
a path computation be performed by the Path Computation Element. 


PCE: Path Computation Element. An entity (component, application, or 
network node) that is capable of computing a network path or route 
based on a network graph and application of computational 
constraints. 


PCEP: PCE Communication Protocol. The communication protocol between 
a Path Computation Client and Path Computation Element. 


PXC: Photonic Cross-Connect 


Q-Factor: The Q-factor provides a qualitative description of the 
receiver performance. It is a function of the optical signal-to- 
noise ratio. The Q-factor suggests the minimum SNR (Signal-to- 
Noise Ratio) required to obtain a specific bit error rate (BER) 
for a given signal. 


ROADM: Reconfigurable Optical Add/Drop Multiplexer. A wavelength- 
selective switching element featuring input and output line side 
ports as well as add/drop tributary ports. 

RWA: Routing and Wavelength Assignment 


Transparent Network: A Wavelength Switched Optical Network that does 
not contain regenerators or wavelength converters. 
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Translucent Network: A Wavelength Switched Optical Network that is 
predominantly transparent but may also contain limited numbers of 
regenerators and/or wavelength converters. 


Tributary: A link or port on a WDM system that can carry 
significantly less than the full multiplex of wavelength signals 
found on the line side links/ports. Typical tributary ports are 
the add and drop ports on an ADM, and these support only a single 
wavelength channel. 


Wavelength Conversion/Converters: The process of converting an 
information-bearing optical signal centered at a given wavelength 
to information with "equivalent" content centered at a different 
wavelength. Wavelength conversion can be implemented via an 
optical-electronic-optical (OEO) process or via a strictly optical 
process. 


WDM: Wavelength Division Multiplexing 


Wavelength Switched Optical Networks (WSONs): WDM-based optical 
networks in which switching is performed selectively based on the 
center wavelength of an optical signal. 


3. Applicability 


There are deployment scenarios for WSONs where not all possible paths 
will yield suitable signal quality. There are multiple reasons; 
below is a non-exhaustive list of examples: 


o WSONs are evolving and are using multi-degree optical cross- 
connects in such a way that network topologies are changing from 
rings (and interconnected rings) to general mesh. Adding network 
equipment such as amplifiers or regenerators to ensure that all 
paths are feasible leads to an over-provisioned network. Indeed, 
even with over-provisioning, the network could still have some 
infeasible paths. 


o Within a given network, the optical physical interface may change 
over the network's life; e.g., the optical interfaces might be 
upgraded to higher bitrates. Such changes could result in paths 
being unsuitable for the optical signal. Moreover, the optical 
physical interfaces are typically provisioned at various stages of 
the network's life span, as needed, by traffic demands. 


O There are cases where a network is upgraded by adding new optical 
cross-connects to increase network flexibility. In such cases, 
existing paths will have their feasibility modified while new 
paths will need to have their feasibility assessed. 
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o With the recent bitrate increases from 10G to 40G and 100G over a 
single wavelength, WSONs will likely be operated with a mix of 
wavelengths at different bitrates. This operational scenario will 
impose impairment constraints due to different physical behavior 
of different bitrates and associated modulation formats. 


Not having an impairment-aware control plane for such networks will 
require a more complex network design phase that needs to take into 
account the evolving network status in terms of equipment and traffic 
at the beginning stage. In addition, network operations such as path 
establishment will require significant pre-design via non-control- 
plane processes, resulting in significantly slower network 
provisioning. 


It should be highlighted that the impact of impairments and use in 
determination of path viability is not sufficiently well established 
for general applicability [G.680]; it will depend on network 
implementations. The use of an impairment-aware control plane, and 
the set of information distributed, will need to be evaluated ona 
case-by-case scenario. 


4.  Impairment-Aware Optical Path Computation 


The basic criterion for path selection is whether one can 
successfully transmit the signal from a transmitter to a receiver 
within a prescribed error tolerance, usually specified as a maximum 
permissible BER. This generally depends on the nature of the signal 
transmitted between the sender and receiver and the nature of the 
communications channel between the sender and receiver. The optical 
path utilized (along with the wavelength) determines the 
communications channel. 


The optical impairments incurred by the signal along the fiber and at 
each optical network element along the path determine whether the BER 
performance or any other measure of signal quality can be met for a 
signal on a particular end-to-end path. 


Impairment-aware path calculation also needs to take into account 
when regeneration is used along the path. [RFC6163] provides 
background on the concept of optical translucent networks that 
contain transparent elements and electro-optical elements such as OEO 
regenerations. In such networks, a generic light path can go through 
a number of regeneration points. 
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Regeneration points could happen for two reasons: 
(i) Wavelength conversion is performed in order to assist RWA in 
avoiding wavelength blocking. This is the impairment-free case 


covered by [RFC6163]. 


(ii) The optical signal without regeneration would be too degraded to 


meet end-to-end BER requirements. This is the case when RWA 
takes into consideration impairment estimation covered by this 
document. 


In the latter case, an optical path can be seen as a set of 
transparent segments. The calculation of optical impairments needs 
to be reset at each regeneration point so each transparent segment 
will have its own impairment evaluation. 


+---+ +----+ +----+ +----- + +----+ +---+ 

| x |---| ma |---| w2 |-----| Ree |-----| N3 |----| 8 | 

+---+ +----+ +----+ +----- + +----+ +---+ 

| <--------------------- > | <-------------------- > | 
Segment 1 Segment 2 

Figure 1. Optical Path as a Set of Transparent Segments 


For example, Figure 1 represents an optical path from node I to 

node E with a regeneration point, REG, in between. This is feasible 
from an impairment validation perspective if both segments (I, Nl, 
N2, REG) and (REG, N3, E) are feasible. 


4.1. Optical Network Requirements and Constraints 


This section examines the various optical network requirements and 
constraints under which an impairment-aware optical control plane may 
have to operate. These requirements and constraints motivate the 
IA-RWA architectural alternatives presented in Section 4.2. 

Different optical network contexts can be broken into two main 
criteria: (a) the accuracy required in the estimation of impairment 
effects and (b) the constraints on the impairment estimation 
computation and/or sharing of impairment information. 
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4.1. 


Lee, 


I; 


Impairment-Aware Computation Scenarios 
No Concern for Impairments or Wavelength Continuity Constraints 


This situation is covered by existing GMPLS with local wavelength 
(label) assignment. 


No Concern for Impairments, but Wavelength Continuity Constraints 


This situation is applicable to networks designed such that every 
possible path is valid for the signal types permitted on the 


network. In this case, impairments are only taken into account 
during network design; after that -- for example, during optical 
path computation -- they can be ignored. This is the case 


discussed in [RFC6163] where impairments may be ignored by the 
control plane and only optical parameters related to signal 
compatibility are considered. 


Approximated Impairment Estimation 


This situation is applicable to networks in which impairment 
effects need to be considered but where there is a sufficient 
margin such that impairment effects can be estimated via such 
approximation techniques as link budgets and dispersion [G.680] 
[G.Sup39]. The viability of optical paths for a particular class 
of signals can be estimated using well-defined approximation 
techniques [G.680] [G.Sup39]. This is generally known as the 
linear case, where only linear effects are taken into account. 
Note that adding or removing an optical signal on the path should 
not render any of the existing signals in the network non-viable. 
For example, one form of non-viability is the occurrence in 
existing links of transients of sufficient magnitude to impact the 
BER of existing signals. 


Much work at ITU-T has gone into developing impairment models at 
this level and at more detailed levels. Impairment 
characterization of network elements may be used to calculate 
which paths are conformant with a specified BER for a particular 
signal type. In such a case, the impairment-aware (IA) path 
computation can be combined with the RWA process to permit more 
optimal IA-RWA computations. Note that the IA path computation 
may also take place in a separate entity, i.e., a PCE. 
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4. 


1 


D. Accurate Impairment Computation 


This situation is applicable to networks in which impairment 
effects must be more accurately computed. For these networks, a 
full computation and evaluation of the impact to any existing 
paths need to be performed prior to the addition of a new path. 
Currently, no impairment models are available from ITU-T, and this 
scenario is outside the scope of this document. 


.2. Impairment Computation and Information-Sharing Constraints 


In GMPLS, information used for path computation is standardized for 
distribution amongst the elements participating in the control plane, 
and any appropriately equipped PCE can perform path computation. For 
optical systems, this may not be possible. This is typically due to 
only portions of an optical system being subject to standardization. 
In ITU-T Recommendations [G.698.1] and [G.698.2], which specify 
single-channel interfaces to multi-channel DWDM systems, only the 
single-channel interfaces (transmit and receive) are specified, while 
the multi-channel links are not standardized. These DWDM links are 
referred to as "black links", since their details are not generally 
available. However, note that the overall impact of a black link at 
the single-channel interface points is limited by [G.698.1] and 
[G.698.2]. 


Typically, a vendor might use proprietary impairment models for DWDM 
spans in order to estimate the validity of optical paths. For 
example, models of optical nonlinearities are not currently 
standardized. Vendors may also choose not to publish impairment 
details for links or a set of network elements, in order not to 
divulge their optical system designs. 


In general, the impairment estimation/validation of an optical path 
for optical networks with black links in the path could not be 
performed by a general-purpose IA computation entity, since it would 
not have access to or understand the black-link impairment 
parameters. However, impairment estimation (optical path validation) 
could be performed by a vendor-specific IA computation entity. Such 
a vendor-specific IA computation entity could utilize standardized 
impairment information imported from other network elements in these 
proprietary computations. 


In the following, the term "black links" will be used to describe 
these computation and information-sharing constraints in optical 
networks. From the control plane perspective, the following options 
are considered: 
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1. The authority in control of the black links can furnish a list of 
all viable paths between all viable node pairs to a computation 
entity. This information would be particularly useful as an input 
to RWA optimization to be performed by another computation entity. 
The difficulty here is that such a list of paths, along with any 
wavelength constraints, could get unmanageably large as the size 
of the network increases. 


2. The authority in control of the black links could provide a 
PCE-like entity a list of viable paths/wavelengths between two 
requested nodes. This is useful as an input to RWA optimizations 
and can reduce the scaling issue previously mentioned. Such a 
PCE-like entity would not need to perform a full RWA computation; 
i.e., it would not need to take into account current wavelength 
availability on links. Such an approach may require PCEP 
extensions for both the request and response information. 


3. The authority in control of the black links provides a PCE that 
performs full IA-RWA services. The difficulty here is that this 
option requires the one authority to also become the sole source 
of all RWA optimization algorithms. 


In all of the above cases, it would be the responsibility of the 
authority in control of the black links to import the shared 
impairment information from the other NEs via the control plane or 
other means as necessary. 


4.1.3. Impairment Estimation Process 


The impairment estimation process can be modeled through the 
following functional blocks. These blocks are independent of any 
control plane architecture; that is, they can be implemented by the 
same or by different control plane functions, as detailed in the 
following sections. 
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4----------------- + 
4------------ + 4----------- + | +------------ + | 
Optical Optical | Optical 

| Interface |------- >| Impairment |--->| | Channel | 
| (Transmit/ | | Path | | | Estimation | | 
| Receive) | | | | | M 
4------------ + 4----------- + | +------------ + | 
| Estimation | 
| || | 
| \/ | 
| +------------ + | 
| | BER/ | | 

| Q Factor | 

+------------ + 
4----------------- + 


Starting from the functional block on the left, the optical interface 
represents where the optical signal is transmitted or received and 
defines the properties at the path endpoints. Even the impairment- 
free case, such as scenario B in Section 4.1.1, needs to consider a 
minimum set of interface characteristics. In such a case, only a few 
parameters used to assess the signal compatibility will be taken into 
account (see [RFC6163]). For the impairment-aware case, these 
parameters may be sufficient or not, depending on the accepted level 
of approximation (scenarios C and D). This functional block 
highlights the need to consider a set of interface parameters during 
the impairment validation process. 


The "Optical Impairment Path" block represents the types of 
impairments affecting a wavelength as it traverses the networks 
through links and nodes. In the case of a network where there are no 
impairments (scenario A), this block will not be present. Otherwise, 
this function must be implemented in some way via the control plane. 
Architectural alternatives to accomplish this are provided in 

Section 4.2. This block implementation (e.g., through routing, 
signaling, or a PCE) may influence the way the control plane 
distributes impairment information within the network. 


The last block implements the decision function for path feasibility. 
Depending on the IA level of approximation, this function can be more 
or less complex. For example, in the case of no IA approximation, 
only the signal class compatibility will be verified. In addition to 
a feasible/not-feasible result, it may be worthwhile for decision 
functions to consider the case in which paths would likely be 
feasible within some degree of confidence. The optical impairments 
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are usually not fixed values, as they may vary within ranges of 
values according to the approach taken in the physical modeling 
(worst-case, statistical, or based on typical values). For example, 
the utilization of the worst-case value for each parameter within the 
impairment validation process may lead to marking some paths as not 
feasible, while they are very likely to be, in reality, feasible. 


4.2.  IA-RWA Computation and Control Plane Architectures 


From a control plane point of view, optical impairments are 
additional constraints to the impairment-free RWA process described 
in [RFC6163]. In IA-RWA, there are conceptually three general 
classes of processes to be considered: Routing (R), Wavelength 
Assignment (WA), and Impairment Validation (IV), i.e., estimation. 


Impairment validation may come in many forms and may be invoked at 
different levels of detail in the IA-RWA process. All of the 
variations of impairment validation discussed in this section are 
based on scenario C ("Approximated Impairment Estimation") as 
discussed in Section 4.1.1. From a process point of view, the 
following three forms of impairment validation will be considered: 


o IV-Candidates 


In this case, an IV process furnishes a set of paths between two 
nodes along with any wavelength restrictions, such that the paths 
are valid with respect to optical impairments. These paths and 
wavelengths may not actually be available in the network, due to 
its current usage state. This set of paths could be returned in 
response to a request for a set of at most K valid paths between 
two specified nodes. Note that such a process never directly 
discloses optical impairment information. Note also that this 
case includes any paths between the source and destination that 
may have been "pre-validated". 


In this case, the control plane simply makes use of candidate 
paths but does not have any optical impairment information. 
Another option is when the path validity is assessed within the 
control plane. The following cases highlight this situation. 


o IV-Approximate Verification 
Here, approximation methods are used to estimate the impairments 
experienced by a signal.  Impairments are typically approximated 


by linear and/or statistical characteristics of individual or 
combined components and fibers along the signal path. 
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o IV-Detailed Verification 


In this case, an IV process is given a particular path and 
wavelength through an optical network and is asked to verify 
whether the overall quality objectives for the signal over this 
path can be met. Note that such a process never directly 
discloses optical impairment information. 


The next two cases refer to the way an impairment validation 
computation can be performed from a decision-making point of view. 


o IV-Centralized 


In this case, impairments to a path are computed at a single 
entity. The information concerning impairments, however, may 
still be gathered from network elements. Depending on how 
information is gathered, this may put additional requirements on 
routing protocols. This topic will be detailed in later sections. 


o IV-Distributed 


In the distributed IV process, approximate degradation measures 
such as OSNR, dispersion, DGD, etc., may be accumulated along the 
path via signaling. Each node on the path may already perform 
some part of the impairment computation (i.e., distributed). When 
the accumulated measures reach the destination node, a decision on 
the impairment validity of the path can be made. Note that such a 
process would entail revealing an individual network element's 
impairment information, but it does not generally require 
distributing optical parameters to the entire network. 


The control plane must not preclude the possibility of concurrently 
performing one or all of the above cases in the same network. For 
example, there could be cases where a certain number of paths are 
already pre-validated (IV-Candidates), so the control plane may set 
up one of those paths without requesting any impairment validation 
procedure. On the same network, however, the control plane may 
compute a path outside the set of IV-Candidates for which an 
impairment evaluation can be necessary. 


The following subsections present three major classes of IA-RWA path 


computation architectures and review some of their respective 
advantages and disadvantages. 
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4.2.1. Combined Routing, WA, and IV 


From the point of view of optimality, reasonably good IA-RWA 
solutions can be achieved if the PCE can conceptually/algorithmically 
combine the processes of routing, wavelength assignment, and 
impairment validation. 


Such a combination can take place if the PCE is given (a) the 
impairment-free WSON information as discussed in [RFC6163] and (b) 
impairment information to validate potential paths. 


4.2.2. Separate Routing, WA, or IV 


Separating the processes of routing, WA, and/or IV can reduce the 
need for the sharing of different types of information used in path 
computation. This was discussed for routing, separate from WA, in 
[RFC6163]. In addition, as was discussed in Section 4.1.2, some 
impairment information may not be shared, and this may lead to the 
need to separate IV from RWA. In addition, if IV needs to be done at 
a high level of precision, it may be advantageous to offload this 
computation to a specialized server. 


The following conceptual architectures belong in this general 
category: 


o R + WA + IV 
Separate routing, wavelength assignment, and impairment 
validation. 


o R + (WA & IV) 
routing separate from a combined wavelength assignment and 
impairment validation process. Note that impairment validation is 
typically wavelength dependent. Hence, combining WA with IV can 
lead to improved efficiency. 


[o] (RWA) + IV 
combined routing and wavelength assignment with a separate 
impairment validation process. 


Note that the IV process may come before or after the RWA processes. 
If RWA comes first, then IV is just rendering a yes/no decision on 
the selected path and wavelength. If IV comes first, it would need 
to furnish a list of possible (valid with respect to impairments) 
routes and wavelengths to the RWA processes. 
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4.2.3. Distributed WA and/or IV 


In the non-impairment RWA situation [RFC6163], it was shown that a 
distributed WA process carried out via signaling can eliminate the 
need to distribute wavelength availability information via an 
interior gateway protocol (IGP). A similar approach can allow for 
the distributed computation of impairment effects and avoid the need 
to distribute impairment characteristics of network elements and 
links by routing protocols or by other means. Therefore, the 
following conceptual options belong to this category: 


o RWA + D(IV) 
combined routing and wavelength assignment and distributed 
impairment validation. 


o R + D(WA & IV) 
routing separate from a distributed wavelength assignment and 
impairment validation process. 


Distributed impairment validation for a prescribed network path 
requires that the effects of impairments be calculated by approximate 
models with cumulative quality measures such as those given in 
[G.680]. The protocol encoding of the impairment-related information 
from [G.680] would need to be agreed upon. 


If distributed WA is being done at the same time as distributed IV, 
then it is necessary to accumulate impairment-related information for 
all wavelengths that could be used. The amount of information is 
reduced somewhat as potential wavelengths are discovered to be in use 
but could be a significant burden for lightly loaded networks with 
high channel counts. 


4.3. Mapping Network Requirements to Architectures 


Figure 2 shows process flows for the three main architectural 
alternatives to IA-RWA that apply when approximate impairment 
validation is sufficient. Figure 3 shows process flows for the two 
main architectural alternatives that apply when detailed impairment 
verification is required. 
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+---------------------------- + 
(a) 
fesse ese ee lee + a ler eec rc ieu * 
| +---------- + 4------- + +--+ | 
UE a. hell | [Routing] | wa | | 
| |candidates| |----- >| +------- + +--+ 
| +---------- + | Combined Processes | 
+-------------- + a eco + 
(b) 
4+----------- + +---------------------- + 
4------- + +--+ +--+ | 
| |Routing| |------- > | | WA | | Iv | | 
4------- + +--+ +--+ | 
tesssr enes + | Distributed Processes| 
Poses SSeS Seas + 
(c) 
Figure 2. Process Flows for the Three Main Approximate Impairment 


Architectural Alternatives 


The advantages, requirements, and suitability of these options are as 
follows: 


o Combined IV & RWA process 


This alternative combines RWA and IV within a single computation 
entity, enabling highest potential optimality and efficiency in 
IA-RWA. This alternative requires that the computation entity 
have impairment information as well as non-impairment RWA 
information. This alternative can be used with black links but 
would then need to be provided by the authority controlling the 
black links. 


o IV-Candidates + RWA process 


This alternative allows separation of impairment information into 
two computation entities while still maintaining a high degree of 
potential optimality and efficiency in IA-RWA. The IV-Candidates 
process needs to have impairment information from all optical 
network elements, while the RWA process needs to have 
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non-impairment RWA information from the network elements. This 
alternative can be used with black links, but the authority in 
control of the black links would need to provide the functionality 
of the IV-Candidates process. Note that this is still very 
useful, since the algorithmic areas of IV and RWA are very 
different and conducive to specialization. 


o Routing + Distributed WA and IV 


In this alternative, a signaling protocol may be extended and 
leveraged in the wavelength assignment and impairment validation 
processes. Although this doesn’t enable as high a potential 
degree of optimality as (a) or (b), it does not require 
distribution of either link wavelength usage or link/node 
impairment information. Note that this is most likely not 
suitable for black links. 


+------------------- + 4R------------ * 
| +----------- +4 + +--+ | +-------- + | 
DNE. | [Routing] [wa] | ER A 
| |Approximate| +------- t +--+ ---->| |Detailed| | 
4+----------- + 4R-------- + 
Combined Processes 
4+----------------------------------- + 4R------------ + 
(a) 
4R-------------- + 4---------------------- + 4R------------ + 
4R---------- + +------- + +--+ 4R-------- * 
| IV | | Routing| | WA | ---->| | Iv | 
| |Candidates| |----- >| +------- + +--+ | | |Detailed| | 
| +---------- + | | Combined Processes | | +-------- + | 
4-------------- + 4 + | | 
(b) 4------------ * 
Figure 3. Process Flows for the Two Main Detailed Impairment 


Validation Architectural Options 


The advantages, requirements, and suitability of these detailed 
validation options are as follows: 


o Combined Approximate IV & RWA + Detailed-IV 
This alternative combines RWA and approximate IV within a single 


computation entity, enabling the highest potential optimality and 
efficiency in IA-RWA while keeping a separate entity performing 


detailed impairment validation. In the case of black links, the 
authority controlling the black links would need to provide all 
functionality. 
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o IV-Candidates + RWA + Detailed-IV 


This alternative allows separation of approximate impairment 
information into a computation entity while still maintaining a 
high degree of potential optimality and efficiency in IA-RWA; 
then, a separate computation entity performs detailed impairment 
validation. Note that detailed impairment estimation is not 


standardized. 
Protocol Implications 
The previous IA-RWA architectural alternatives and process flows make 
differing demands on a GMPLS/PCE-based control plane. This section 
discusses the use of (a) an impairment information model, (b) the PCE 
as computation entity assuming the various process roles and 
consequences for PCEP, (c) possible extensions to signaling, and 
(d) possible extensions to routing. This document is providing this 
evaluation to aid protocol solutions work. The protocol 
specifications may deviate from this assessment. The assessment of 
the impacts to the control plane for IA-RWA is summarized in 
Figure 4. 
FH SSeS SSS onen ++ ++- Faser phita + 
| IA-RWA Option | PCE | Sig | Info Model | Routing | 
Sean E nr pans +----- eie akut Ent ee en + 
| Combined | Yes | No | Yes | Yes | 
| IV& RMA | | | | | 
+2 HA anne penc t----- 4------------ 4--------- t 
| IV-Candidates | Yes | No | Yes | Yes | 
| fma | | — | | | 
4-------------------- T----- T----- 4------------ 4--------- + 
| Routing + | No | ves | Yes | No 
[Distributed IV, RWA | | | | 
4-------------------- T----- T----- 4------------ 4--------- t 
Figure 4.  IA-RWA Architectural Options and Control Plane Impacts 
1. Information Model for Impairments 


As previously discussed, most IA-RWA scenarios rely, to a greater or 
lesser extent, on a common impairment information model. A number of 
ITU-T Recommendations cover both detailed and approximate impairment 
characteristics of fibers, a variety of devices, and a variety of 
subsystems. An impairment model that can be used as a guideline for 
optical network elements and assessment of path viability is given 

in [G.680]. 
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It should be noted that the current version of [G.680] is limited to 
networks composed of a single WDM line system vendor combined with 
OADMs and/or PXCs from potentially multiple other vendors. This is 
known as "Situation 1" and is shown in Figure 1-1 of [G.680]. It is 
planned in the future that [G.680] will include networks 
incorporating line systems from multiple vendors, as well as OADMs 
and/or PXCs from potentially multiple other vendors. This is known 
as "Situation 2" and is shown in Figure 1-2 of [G.680]. 


For the case of distributed IV, this would require more than an 
impairment information model. It would need a common impairment 
"computation" model. In the distributed IV case, one needs to 
standardize the accumulated impairment measures that will be conveyed 
and updated at each node. Section 9 of [G.680] provides guidance in 
this area, with specific formulas given for OSNR, residual 
dispersion, polarization mode dispersion/polarization-dependent loss, 
and effects of channel uniformity. However, specifics of what 
intermediate results are kept and in what form would need to be 
standardized for interoperability. As noted in [G.680], this 
information may possibly not be sufficient, and in such a case, the 
applicability would be network dependent. 


5.2. Routing 


Different approaches to path/wavelength impairment validation give 
rise to different demands placed on GMPLS routing protocols. In the 
case where approximate impairment information is used to validate 
paths, GMPLS routing may be used to distribute the impairment 
characteristics of the network elements and links based on the 
impairment information model previously discussed. 


Depending on the computational alternative, the routing protocol may 
need to advertise information necessary to the impairment validation 
process. This can potentially cause scalability issues, due to the 

high volume of data that need to be advertised. Such issues can be 

addressed by separating data that need to be advertised only rarely 

from data that need to be advertised more frequently, or by adopting 
other forms of awareness solutions as described in previous sections 
(e.g., a centralized and/or external IV entity). 


In terms of scenario C in Section 4.1.1, the model defined by [G.680] 
will apply, and the routing protocol will need to gather information 
required for such computations. 


In the case of distributed IV, no new demands would be placed on the 
routing protocol. 
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5.3. Signaling 


The largest impacts on signaling occur in the cases where distributed 
impairment validation is performed. In this case, it is necessary to 
accumulate impairment information, as previously discussed. In 
addition, since the characteristics of the signal itself, such as 
modulation type, can play a major role in the tolerance of 
impairments, this type of information will need to be implicitly or 
explicitly signaled so that an impairment validation decision can be 
made at the destination node. 


It remains for further study whether it may be beneficial to include 
additional information to a connection request, such as desired 
egress signal quality (defined in some appropriate sense) in 
non-distributed IV scenarios. 


5.4. PCE 


In Section 4.2, a number of computational architectural alternatives 
were given that could be used to meet the various requirements and 
constraints of Section 4.1. Here, the focus is on how these 
alternatives could be implemented via either a single PCE or a set of 
two or more cooperating PCEs, and the impacts on the PCEP. This 
document provides this evaluation to aid solutions work. The 
protocol specifications may deviate from this assessment. 


5.4.1. Combined IV & RWA 


In this situation, shown in Figure 2(a), a single PCE performs all of 
the computations needed for IA-RWA. 


o Traffic Engineering (TE) Database requirements: WSON topology and 
switching capabilities, WSON WDM link wavelength utilization, and 
WSON impairment information. 


o PCC to PCE Request Information: Signal characteristics/type, 
required quality, source node, and destination node. 


o PCE to PCC Reply Information: If the computations completed 
successfully, then the PCE returns the path and its assigned 
wavelength. If the computations could not complete successfully, 
it would be potentially useful to know why. At a minimum, it is 
of interest to know if this was due to lack of wavelength 
availability, impairment considerations, or both. The information 
to be conveyed is for further study. 
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5.4.2.  IV-Candidates + RWA 


In this situation, as shown in Figure 2(b), two separate processes 
are involved in the IA-RWA computation. This requires two 
cooperating path computation entities: one for the IV-Candidates 
process and another for the RWA process. In addition, the overall 
process needs to be coordinated. This could be done with yet another 
PCE, or this functionality could be added to one of a number of 
previously defined entities. This later option requires that the RWA 
entity also act as the overall process coordinator. The roles, 
responsibilities, and information requirements for these two 
entities, when instantiated as PCEs, are given below. 


RWA and Coordinator PCE (RWA-Coord PCE): 


The RWA-Coord PCE is responsible for interacting with the PCC and 
for utilizing the IV-Candidates PCE as needed during RWA 


computations. In particular, it needs to know that it is to use 
the IV-Candidates PCE to obtain a potential set of routes and 
wavelengths. 


o TE Database requirements: WSON topology and switching 
capabilities, and WSON WDM link wavelength utilization (no 
impairment information). 


o PCC to RWA PCE request: same as in the combined case. 
o RWA PCE to PCC reply: same as in the combined case. 


o RWA PCE to IV-Candidates PCE request: The RWA PCE asks for a 
set of at most K routes, along with acceptable wavelengths 
between nodes specified in the original PCC request. 


o IV-Candidates PCE reply to RWA PCE: The IV-Candidates PCE 
returns a set of at most K routes, along with acceptable 


- 


wavelengths between nodes specified in the RWA PCE request. 


IV-Candidates PCE: 


The IV-Candidates PCE is responsible for impairment-aware path 
computation. It need not take into account current link 
wavelength utilization, but this is not prohibited. The 
IV-Candidates PCE is only required to interact with the RWA PCE as 
indicated above, and not the initiating PCC. Note: The 

RWA-Coord PCE is also a PCC with respect to the IV-Candidate. 
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o TE Database requirements: WSON topology and switching 
capabilities, and WSON impairment information (no information 
link wavelength utilization required). 


Figure 5 shows a sequence diagram for the possible interactions 
between the PCC, RWA-Coord PCE, and IV-Candidates PCE. 


+---+ +------------- + +----------------- + 
|Pcc | |RWA-Coord PCE| |Iv-Candidates PCE 
+-+-+ +------ +------ + +--------- +------- + 

(a) | | 

| NO X EM | | 

| S| | 

| | | 

| es E | 

| | VV Vi > 

| | | 

| | | 

| | (c) toss 

___'rT1 agr 

| E | 

| | | 

| (d) ree | 

D eee | 

[osse | | 
Figure 5. Sequence Diagram for the Interactions between the PCC, 


RWA-Coord PCE, and IV-Candidates PCE 


In step (a), the PCC requests a path that meets specified quality 
constraints between two nodes (A and Z) for a given signal 
represented either by a specific type or a general class with 
associated parameters. In step (b), the RWA-Coord PCE requests up to 
K candidate paths between nodes A and Z, and associated acceptable 
wavelengths. The term "K candidate paths" is associated with the k 
shortest path algorithm. It refers to an algorithm that finds 
multiple k short paths connecting the source and the destination in a 
graph allowing repeated vertices and edges in the paths. See details 
in [Eppstein]. 
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In step (c), the IV-Candidates PCE returns this list to the 
RWA-Coord PCE, which then uses this set of paths and wavelengths as 


input (e.g., a constraint) to its RWA computation. In step (d), the 
RWA-Coord PCE returns the overall IA-RWA computation results to 
the PCC. 


5.4.3. Approximate IA-RWA + Separate Detailed-IV 


Previously, Figure 3 showed two cases where a separate detailed 
impairment validation process could be utilized. It is possible to 
place the detailed validation process into a separate PCE. Assuming 
that a different PCE assumes a coordinating role and interacts with 
the PCC, it is possible to keep the interactions with this separate 
IV-Detailed PCE very simple. Note that, from a message flow 
perspective, there is some inefficiency as a result of separating the 
IV-Candidates PCE from the IV-Detailed PCE in order to achieve a high 
degree of potential optimality. 


IV-Detailed PCE: 


o TE Database requirements: The IV-Detailed PCE will need optical 
impairment information, WSON topology, and, possibly, WDM link 
wavelength usage information. This document puts no restrictions 
on the type of information that may be used in these computations. 


o RWA-Coord PCE to IV-Detailed PCE request: The RWA-Coord PCE will 
furnish signal characteristics, quality requirements, path, and 
wavelength to the IV-Detailed PCE. 


o IV-Detailed PCE to RWA-Coord PCE reply: The reply is essentially a 
yes/no decision as to whether the requirements could actually be 
met. In the case where the impairment validation fails, it would 
be helpful to convey information related to the cause or to 
quantify the failure, e.g., so that a judgment can be made 
regarding whether to try a different signal or adjust signal 
parameters. 


Figure 6 shows a sequence diagram for the interactions corresponding 
to the process shown in Figure 3(b). This involves interactions 
between the PCC, RWA PCE (acting as coordinator), IV-Candidates PCE, 
and IV-Detailed PCE. 


In step (a), the PCC requests a path that meets specified quality 
constraints between two nodes (A and Z) for a given signal 
represented either by a specific type or a general class with 
associated parameters. In step (b), the RWA-Coord PCE requests up to 
K candidate paths between nodes A and Z, and associated acceptable 
wavelengths. In step (c), the IV-Candidates PCE returns this list to 
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the RWA-Coord PCE, which then uses this set of paths and wavelengths 
as input (e.g., a constraint) to its RWA computation. In step (d), 
the RWA-Coord PCE requests a detailed verification of the path and 
wavelength that it has computed. In step (e), the IV-Detailed PCE 
returns the results of the validation to the RWA-Coord PCE. Finally, 
in step (f), the RWA-Coord PCE returns the final results (either a 
path and wavelength, or a cause for the failure to compute a path and 
wavelength) to the PCC. 


+---------- + +-------------- + +------------ + 
+---+ |RWA-Coord | |Iv-Candidates | |IV-Detailed | 
|Pcc | | PCE | | PCE | | PCE | 
+-+-+ +----+----- + +------ +------- + +----- +------ + 

| exco. (a) | | | 
is, aie ol | | 
\--> 
| (b) | | 
| ieee e | | 
| | | | 
| | | | 
| | (ae | | 
Seat: F 
| on | | 
| | | 
| [cet (d) | 
| | ae E | 
| | VUN LL LL >| 
| | Ä 
(e) CNN * 
| ie ge ce Ead o dee wo | 
| [|<---- tr | 
| (EJ. NN | 
NEC | 
PRA | 
Figure 6. Sequence Diagram for the Interactions between the PCC, 


RWA-Coord PCE, IV-Candidates PCE, and IV-Detailed PCE 
6. Manageability and Operations 
The issues concerning manageability and operations are beyond the 


scope of this document. The details of manageability and operational 
issues will have to be deferred to future protocol implementations. 
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On a high level, the GMPLS-routing-based architecture discussed in 
Section 5.2 may have to deal with how to resolve potential scaling 
issues associated with disseminating a large amount of impairment 
characteristics of the network elements and links. 


From a scaling point of view, the GMPLS-signaling-based architecture 
discussed in Section 5.3 would be more scalable than other 
alternatives, as this architecture would avoid the dissemination of a 


large amount of data to the networks. This benefit may come, 
however, at the expense of potentially inefficient use of network 
resources. 


The PCE-based architectures discussed in Section 5.4 would have to 
consider operational complexity when implementing options that 
require the use of multiple PCE servers. The most serious case is 
the option discussed in Section 5.4.3 ("Approximate IA-RWA + Separate 
Detailed-IV"). The combined IV & RWA option (which was discussed in 
Section 5.4.1), on the other hand, is simpler to operate than are 
other alternatives, as one PCE server handles all functionality; 
however, this option may suffer from a heavy computation and 
processing burden compared to other alternatives. 


Interoperability may be a hurdle to overcome when trying to agree on 
some impairment parameters, especially those that are associated with 
the black links. This work has been in progress in ITU-T and needs 
some more time to mature. 


7. Security Considerations 


This document discusses a number of control plane architectures that 
incorporate knowledge of impairments in optical networks. If such an 
architecture is put into use within a network, it will by its nature 
contain details of the physical characteristics of an optical 
network. Such information would need to be protected from 
intentional or unintentional disclosure, similar to other network 
information used within intra-domain protocols. 


This document does not require changes to the security models within 
GMPLS and associated protocols. That is, the OSPF-TE, RSVP-TE, and 
PCEP security models could be operated unchanged. However, 
satisfying the requirements for impairment information dissemination 
using the existing protocols may significantly affect the loading of 
those protocols and may make the operation of the network more 
vulnerable to active attacks such as injections, impersonation, and 
man-in-the-middle attacks. Therefore, additional care may be 
required to ensure that the protocols are secure in the impairment- 
aware WSON environment. 
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Furthermore, the additional information distributed in order to 
address impairment information represents a disclosure of network 
capabilities that an operator may wish to keep private. 
Consideration should be given to securing this information. For a 
general discussion on MPLS- and GMPLS-related security issues, see 
the MPLS/GMPLS security framework [RFC5920] and, in particular, text 
detailing security issues when the control plane is physically 
separated from the data plane. 
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